home *** CD-ROM | disk | FTP | other *** search
/ Language/OS - Multiplatform Resource Library / LANGUAGE OS.iso / preccx / prccx230.msd / precc231.pat < prev    next >
Text File  |  1993-07-19  |  4KB  |  92 lines
  1. From ptb@uk.ac.cambridge.engineering Sat May 15 21:48:56 1993
  2. Received: from uk.ac.oxford by prg.oxford.ac.uk 
  3.      id AA14271; Sat, 15 May 93 15:59:50 +0100
  4. Received: from gray.computing-service-internal.cambridge.ac.uk 
  5.           by oxmail.ox.ac.uk with SMTP (PP) id <04391-0@oxmail.ox.ac.uk>;
  6.           Sat, 15 May 1993 15:50:27 +0100
  7. Received: from xrly.eng.cam.ac.uk by ppsw1.cam.ac.uk 
  8.           with SMTP-CAM (PP-6.0) as ppsw.cam.ac.uk 
  9.           id <26432-0@ppsw1.cam.ac.uk>; Sat, 15 May 1993 15:51:06 +0100
  10. From: Peter "T." Breuer <ptb@uk.ac.cambridge.engineering>
  11. Message-Id: <7128.9305151450@club.eng.cam.ac.uk>
  12. Subject: the foo.bar C expression for precc
  13. Mailer: Elm [revision: 70.30]
  14. Status: OR
  15.  
  16.  
  17. There  is an omission in precc 2.23-2.31 that causes it not to recognise
  18. C expressions of the form `foo.bar' as valid.  `foo->bar' is handled OK,
  19. and so therefore is `(&foo)->bar', which is one work-around.
  20.  
  21. # define bar(foo) foo.bar
  22.  
  23. is  another.  C  expressions  can  occur  in  precc  definitions  as the
  24. parameters of productions and non-terminals,  and in logical tests,  and
  25. literal token matches.
  26.  
  27. I never intended to make precc perfect at C expressions - one would need
  28. a macro interpreter to do that -  but this could be  annoying,  so  I'll
  29. issue the following patch for those who are really very annoyed.
  30.  
  31. I  judged it crazy to try and match the C infix operators too precisely,
  32. so precc accepts as an infix any multi-symbol combination from  the  set
  33. <>=!|&%/*-+ and as you can see, I forgot to include dot.  You could mend
  34. this very easily if I gave you the precc  specification  in  precc-code,
  35. but you don't have that (I may release it with 2.40).
  36.  
  37. As  it  is,  you  will  have  to  mend the generated code.  The simplest
  38. revision I can think of is to add dot  into  the  <>=!|&%/*-+  list,  by
  39. changing the definition of the binopone() parser.  Let's leave aside the
  40. question of why I used a parser instead of a lexical-level  function  of
  41. some kind. Maybe there aren't that many C expressions in a precc script,
  42. and this way is just easy to maintain.
  43.  
  44. This  is in the contiguous chain of parsers in the preccx.c script which
  45. ends with  the  STATUS  binopone()  definition.  The  numbering  may  be
  46. slightly different depending on whether you have 2.23,  2.30 or 2.31, so
  47. look for the RIGHTANGLEBRACKET or binopone in the code. This is from
  48. the (minor) revision 2.31, which is basically the same as 2.30.
  49.  
  50. ************* begin new code ***************************************
  51. static STATUS hid329(){
  52. return(p_exactly0(RIGHTANGLEBRACKET(1)));
  53. }
  54. static STATUS hid329a(){
  55. return(p_exactly0('.'));
  56. }
  57. static STATUS hid329b(){
  58. PARSER hid329, hid329a;
  59. return(p_orparse0n(TOPARSER hid329,0,TOPARSER hid329a,0));
  60. }
  61. static STATUS hid330(){
  62. PARSER hid328, hid329b;
  63. return(p_orparse0n(TOPARSER hid328,0,TOPARSER hid329b,0));
  64. }
  65. ************* end new code ****************************************
  66.  
  67.  
  68. ************* begin old code ***************************************
  69. static STATUS hid329(){
  70. return(p_exactly0(RIGHTANGLEBRACKET(1)));
  71. }
  72. static STATUS hid330(){
  73. PARSER hid328, hid329;
  74. return(p_orparse0n(TOPARSER hid328,0,TOPARSER hid329,0));
  75. }
  76. ************* end old code ****************************************
  77.  
  78.  
  79. As  you  can see,  I have just added an extra alternative into the list.
  80. The precc definition script from which this is generated now reads
  81.  
  82. @ binopone = .....
  83. @          | <RIGHTANGLEBRACKET(1)>
  84. @          | <'.'>
  85.  
  86. (the hideous RIGHTANLEBRACKET macro can be got rid of in 2.40 and above
  87. where <'>'> is handled properly)
  88.  
  89. --
  90. Peter
  91.  
  92.